GEOS and the initial RAMLink/REU directive from CMD is to use partition number 31 ..it is ONLY a convienent partition to use so as to NOT have you inadvertantly delete that partition when using RAM-TOOLS.
Anyway, ACE expects the DACCs numbered a certain way. prt#30 INDIRECT REU is REU ram and the first DACC created. prt#31 RL-RAM is made up of a portion of RAMLink's SIMM Ram
Here's my RAMLink partition's info:
ramlink partitions
num name type size address
----------------------------------------
00 system sys 16 $97f000
01 81 ramdisk 1581 3200 $180000
02 geowrite 1581 3200 $248000
03 geopaint 1581 3200 $310000
04 geopublish 1581 3200 $3d8000
05 geoprogrammer 1581 3200 $4a0000
06 dialogue 1581 3200 $568000
07 csdos-bbr4 1581 3200 $630000
08 qwkrr 1581 3200 $6f8000
09 downloads natv 4864 $7c0000 REU
30 indirect-reu dacc 6144 $000000 <-first prt. created 1.5 meg
31 rl-ram dacc 2048 $8f0000 <-last prt. created 512 k
38672 sectors allocated NOTE: GEOS finds first DACC prt. created
00240 sectors free NO matter what number the prt. is. So
38912 sectors total the REU as prt# 30 is OK!
----------------------------------------
default device 16
default partition 07
----------------------------------------
FD> I.E. [ @r-p:rl-ram=dacc ] That way I
FD> did not need to delete all other
Hmm? maybe thats why I couldn't do the renaming of the partition cause I was doing something akin to file renaming: @rp:newname=oldname or at least that is *if* your method means that your RL partition just renames it ..not needing the OLDNAME ..and your showing above "dacc" is the TYPE of partition and not the oldname. Anyway, I think, I might give it a try. I'm leary of it though. But, since my RL partition is already a DACC and the last partition created.. well, I won't have trouble recreating it via RAM-TOOLS. You do ..do a @cp 31 first and then follow up with the "@r-p:".. correct.
----------------------------
ACE Help
From : mbendure@infinet.com
Prof. Filch (pvaculin@xmission.xmission.com) wrote:
: I got the ACE 14 OS and find that it works GREAT. I particuularly like ACE TERM. I have one question though that is puzzling me. To me it seems that the documentation on the 'fx' protocol is a bit hazy. Do I need to compile the host portion on the host before it will work? I welcome your assistance and comments.
Your correct, the Unix version of FX has to be compiled on your Host machine using something like GCC. I simply took the fx.c file, place it in a directory on my host and issued the following command:
gcc fx.c
This creates a file called 'a.out' that I just renamed to fx. I have a feeling there is a way to do that all in one command, but this procedure seemed to work for me. :)
Once you get FX compiled on your host, your ready to start downloading. If you have a few files to download, you simply type in this command:
fx -k -b binaryFilename
This command will setup a 1K packet size and transfer the 'binaryFilename' file to your computer. You then have to quit ACEterm by issuing the C= Q or C= E command, then type the word fx and the file(s) will be sent to your computer on the current directory. To return to your host, simply type term and your back online.
Fx is a little more tedious to handle than say Y-Modem of Dialogue 128, but the advantage is the resizable packet sizes and of course the speed. :) For internet cessions, I prefer to use ACEterm over anything else out there. But for regular BBS sessions, Dialogue 128 is my term of choice. Once Craig puts Zmodem or Ymodem in ACEterm, that may change.
--------------------------
Bruce McFarling <brmcf@utkux1.utk.edu> writes:
> You don't need to have all of the ACE files in the disk at the same time. In particular, the external commands don't have to be on the disk that you boot ACE off of. [But note: since the command shell is now external, you'll probably want to have a copy of the command shell on each work disk]
There is just barely enough room to copy the command shell onto a ramdisk, so you don't have to have it on each work disk.
>PS: Regarding PKZIP 2.04 format unzipping on ACE, I was wrong in suspecting that there are patent problems there. It's PKARC and Unix Compress that have patent problems. The inflation algorithm is OK. However, it uses a 32K window, so I'm not sure how to fit into an ACE program that will run on an unexpanded C64 with a single 1541.
I am planning to make another variation of ACE called "ACE Plus" which will be intended for a C128 with some expanded memory. It will include all of the regular ACE stuff plus custom device drivers for the standard 1571, 1581, FD-2000, FD-4000, CMD HD, and RAMLink devices, which would include caching and will be much faster for regular file accessing then even JiffyDOS. To accommodate this extra code/buffer space, the user-program space will be moved to RAM1, where it will be 63,744 bytes in size. The 40-column screen support will have to be cut, since I think that it will interfere with REU DMA. Most of the internal memory will be dedicated to the system, and expanded memory will be used for the regular application-bulk-data storage.
So, it will be possible to run programs like PKZIP with ACE, even if only on a big C128 system. (It may be possible to also do such a thing with a C64 with expanded internal memory, but, alas, I have no test equipment...).
>I got the ACE 14 OS and find that it works GREAT. I particuularly like [ACEterm]. I have one question though that is puzzling me. To me it seems that the documentation on the 'fx' protocol is a bit hazy. Do I need to compile the host portion on the host before it will work?
Yes, you do. You will need an ANSI-C compiler. "gcc" is a good program to use. Also, because of differences between compilers and Unixes, you may have to change the following lines of the program that are near the top:
/* #define GOT
ULONG
ALREADY */
/* #define GOT
UCHAR
ALREADY */
/* #define GOT
BOOL
ALREADY */
#define GOT
GMT
OFFSET
Comment out one of these defines to deactivate it (like the first three), or make it "live" to acticate it (like the last one). If your compiler complains about the data type "ulong" already being defined, then make the
GOT
ULONG
ALREADY declaration live. Same for the types "uchar" and "bool",
with the
GOT
UCHAR
ALREADY and GOT
BOOL
ALREADY declarations. And if your
compiler complains about "tmbuf->tm
gmtoff: member of structure or union
required", then you must comment out the GOT
GMT
OFFSET declaration.
If your compiler complains about every function declaration being wrong,then you are not using an ANSI-C compiler. Maybe someday all Unix systems will be the same.
Keep on Hackin'!
-Craig Bruce
-----------------------------
Michael Bendure <mbendure@infinet.com> writes:
> Your correct, the Unix version of FX has to be compiled on your Host machine using something like GCC. I simply took the fx.c file, place it in a directory on my host and issued the following command: gcc fx.c
This creates a file called 'a.out' that I just renamed to fx. I have a feeling there is a way to do that all in one command, but this procedure seemed to work for me. :)
The best command line to use is:
gcc -O -s fx.c -o fx
This optimizes the object code, strips out the useless symbolic information from the executable (which needlessly occupies space).
> Once you get FX compiled on your host, your ready to start downloading. If you have a few files to download, you simply type in this command: fx -k -b binaryFilename
You can set the default packet sizes for different types of transfers by adjusting the following defines near the top of the file:
#define DEFAULT
UPLOAD
TEXT
SIZE 1024
#define DEFAULT
UPLOAD
BINARY
SIZE 1024
#define DEFAULT
DOWNLOAD
TEXT
SIZE MAX
DATA
#define DEFAULT
DOWNLOAD
BINARY
SIZE MAX
DATA
Where "MAX DATA" is defined earlier to be 64K. For the best results, you should set these to the maximim value that gives you reliable operation. You can experiment with your Unix system(s) to see what works well. A 1K packet size is kind of a lowest common denominator, since other protocols require that packet size. Of course, smaller packet sizes also let you keep a closer eye on what's going on during the transfer.
Also, in the above example, the "-b" flag is redundant, since the files given are assumed to be binary until you use the "-t" flag to specify otherwise.
Keep on Hackin'!
-Craig Bruce
--------------------------
From : Ismael Cordeiro
In a message to Jean Parrot, Brian Stefanish wrote:
> JP> I studied a UNIX manual for a few hours but I can not to save my skin, see how I could import any UNIX PRGs and use them in ACE...
BS> That is probably because the ACE shell is nothing like the Bourne Shell, or C Shell, or Korn Shell, or just not a full scale version. Your best bet would be to make a ACE Shell in UNIX, and then try and port that to the Ace unix on c64
The reason to our not being able to import Unix programs into ACE is very simple, Brian. ACE is NOT Unix. The first thing Craig Bruce says in the docs is that "ACE is an operating system for the Commodore 128 and Commodore 64 that provides a Unix-like command-shell environment". The point is the operating system (OS), not the shell. The shell is a human- oriented interface between the user and the OS, like CCP.COM in CP/M and COMMAND.COM in MS-DOS. CS-DOS has a MS-DOS-like shell, or interface, but it doesn't mean we can import MS-DOS programs into it. GEOS has a graphic interface, or shell, but it doesn't mean that we can import Geoworks, MacIntosh, Windows or X-Window programs into it.
Ismael
---------------------------
pre7874@u.cc.utah.edu (Perry Eidelbus) writes:
>Now, to direct my post to someone else. Thank you for your offer, Mr. Bruce. I'll have to send you my customized 'font80.nova wide' file, once my server fixes the rb/rc/rx commands--aargh! Sorry I haven't replied to you sooner, but with my news server's crash, it's been a devil of a time trying to recover old messages. I thought I could figure out how to modify the ACE 4-bit charset myself, but it's not at all as simple as Novaterm (giveaways with the zero bits in the first char, a space). I've been looking at it and still can't figure out how you store the character images.
The format is a little more complicated than raw character sets. The format includes four pieces:
(1) the header,
(2) the graphic-character palette,
(3) the 8-bit-wide raw characterset, and
(4) the 4-bit-wide raw characterset.
More specifically (note that the offsets don't include the two-byte loading address at the start of all PRG files):
OFFSET SIZE DESC
------ ---- -----
$0000 1 the petscii letter "c": code $43
$0001 1 code $cb
$0002 1 code $06
$0003 1 format version: $01
$0004 1 character sets present: $c0
$0005 1 reverseable character set: $80, $00==not
$0006 10 reserved: $00s
$0010 32 character palette
$0030 2048 8-bit-wide raw character set font, 8x8 cells
$0830 2048 4-bit-wide raw character set font, 8x8 cells, dual 4-bit
images
$1030 - SIZE
The first three bytes identify the file as being an ACE character set. The only current version is $01. The "character sets present" field indicates which character images are present: $80==8-bit-wide, $40==4-bit-wide, and $c0==both (currently the only supported option). The "reversable" flag tells whether the character set includes the regular Commodore characters in the regular positions and the inverse images of the regular Commodore characters in the normal ACE positions, or not. This information is used for displaying reversed characters on the 40-column screen. For example, "acechr-commodore" has a value of $80 for this field, whereas "acechr-iso8859-1" has a value of $00.
The character palette gives the codes of 32 graphics characters to be used for composing boxes, etc. The images for the codes have the following description per position (the characters in parentheses are approxiate ASCII characters):
Applications will be using this palette to figure out which graphics characters to use for various effects. This palette is necessary because the character codes may be different in different character sets.
The 8-bit-wide images are in the standard format (eight bytes per character). The 4-bit-wide images are in the same format as the 8-bit-wide images, except that each 4-bit-wide image is repeated on both the high and low nybbles of the eight bytes that define the character.
This representation allows the raw image to be editable with a standard character set editor, and allows the soft-80 screen driver to work efficiently.
BTW, are there any copyright problems with using other programs's fonts?
("font80.nova wide" obviously comes form NovaTerm).
Keep on Hackin'!
-Craig Bruce
--------------------
From : Michael Bendure
BM> Also, I have been fooling around with AceTerm and agree that is quite program for speed, but, how do you use fx download protocol on your shell account? Thanks..
On ccnga.uwaterloo.ca in /pub/cbm/os/ace there is a file called
fx102.c. This is the UNIX source code for the UNIX side of FX. You
have to compile that using:
gcc -O -s fx102.c
Then rename the resulting a.out file to fx, using:
mv ./a.out fx
This will give you a fx protocol on your home directory. To download a file, put the file in the same directory as fx and type:
fx -k -b filename (This is for a binary file using 1k packet size)
Then hit C=Q to quit the term, which will bring you to the ACE prompt. Type fx from there and the transfer will begin. Once completed, you can type:
term
And you will be back at you UNIX prompt as if you never left. To upload a file from your Commodore to the Shell account, activate fx from the UNIX shell account by simply typing:
fx
Then quit the term program as before using C=Q. From the ACE prompt, type:
fx -k -b filename (Again using 1k packet size on a binary file)
The transfer will then begin and when its completed type term again and your back at the UNIX prompt once again. Not really that complicated, but you can transfer text files and also change the packet size to whatever you like, up to 20k on the Commodore side and 78k on the UNIX side. I haven't played around much with the different packet sizes, but plan to eventually. :) You can also configure the buffer sizes of the Swiftlink, to increase them. I set mine to 1k, I think the default is 255 bytes, but don't quote me on that.
This should at least get you started. The docs pretty much covers all this stuff, or at least I thought it did. Its been a while since I read them, and I never print all that stuff out. I usually just read it when I need it, using the MORE feature of ACE. :) Since my printer is on the blink I won't waste the paper by having to print it several times to get a good copy. :(
